QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940346.txt

Internet Message Format | 1994-11-13 | 23KB

Date: Thu, 20 Oct 94 04:30:24 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: List
Subject: Ham-Digital Digest V94 #346
To: Ham-Digital


Ham-Digital Digest          Thu, 20 Oct 94       Volume 94 : Issue  346

Today's Topics:
                        ampr.org conventions?
              Does a TM 732 E/A can work at 9600 bauds ?
                     FBB or MSYS mailing lists???
                             GPS prices?
                     NOS: problem with ALIAS file
                                RTTY ?
                     Send .COM files over e-mail
                 WANT: Computer Aided Dispatch system
                       Where is "ethrax25.zip"?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 20 Oct 1994 02:45:43 GMT
From: [e-mail]
Subject: ampr.org conventions?

In <38391j$[e-mail]>, [e-mail] (Steve McKinty - SunSoft ICNC Grenoble) writes:
>I have several systems tied together on a home ethernet. I want to
>assign a domainname covering all of them, within the ampr.org domain.
>
>Assuming I get the appropriate IP addresses, what is the convention
>for this?  Would a domain of <mycallsign>.ampr.org be normal, with
>the systems configured as <system1>.<mycallsign>.ampr.org etc.?

Brian Kantor ( [e-mail] I think ) will have the right answer
since he runs the ampr.org dns. I've been doing slip.callsign.ampr.org or
linux.callsign.ampr.org, etc for local users. No one's complained yet.
Check with Brian if your worried.

73's  de  Jack  -  kf5mg
Internet        -  [e-mail]            -  44.28.0.14
                -  [e-mail]              -  work (looking  for)
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home [phone]
+=======================================================================+
+                   D.A.M. - Mothers Against Dyslexia                   +
+=======================================================================+

------------------------------

Date: 20 Oct 1994 08:07:24 GMT
From: [e-mail] (KENWOOD)
Subject: Does a TM 732 E/A can work at 9600 bauds ?

 First, thanks to read this news,

 Subject say all but I'm added these details :


     - does someone have make some homebrew about that ?
     - if the TM 732 can work at 9600 is it directly (original featured)
       or with a particular mod.

     - notice I have a 732 E on witch I av perform the E5 mod (see file
       TM732.mod in /pub/hamradio/mods/kenwood on oak.oakland.edu)


     Thanks and 73 to all

Jean-Christophe MONIER
Ingenieur Reseaux / Networks Engineer
Athesa - C.E.A. Defense - France
E-Mail : [e-mail]
Phone : [phone]


------------------------------

Date: Wed, 19 Oct 1994 12:44:45 GMT
From: [e-mail] (John Rumball)
Subject: FBB or MSYS mailing lists???

Thank you for reading this posting.  I am wondering if there are any FBB or
MSYS related mailing lists I can subscribe to, similar to the NOS-BBS list?

If you know of such a list, please pass along the details (ie. how to
subscribe) to me.

Thank you in advance and 73.


de John, VA3BUS


--
/------\ Ontario         JOHN RUMBALL
| ()() | Ministry of     District Systems Officer     [e-mail]
|  ()  | Natural         Sudbury, ON Canada     va3bus@va3bus.#ne.on.can.noam
\------/ Resources       [phone] ext.278

------------------------------

Date: Thu, 20 Oct 1994 02:50:23 GMT
From: [e-mail]
Subject: GPS prices?

I'd like to play with mobile packet and GPS maping. Anyone know where
I can find a REALLY cheap GPS device with a built in serial port? Thanks.

73's  de  Jack  -  kf5mg
Internet        -  [e-mail]            -  44.28.0.14
                -  [e-mail]              -  work (looking  for)
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home [phone]
+=======================================================================+
+                   D.A.M. - Mothers Against Dyslexia                   +
+=======================================================================+

------------------------------

Date: Wed, 19 Oct 1994 17:24:00 GMT
From: [e-mail] (Guy Boulais)
Subject: NOS: problem with ALIAS file

Hi, in my ALIAS file of NOS I made an entry like this:
joe    [e-mail]



When I try to send a mail to "joe", the smtp module tries to send the
mail to abc123.edu, but to user "joe" instead of "fred".  So the
receiver returns me a message telling that user "joe" is unknown.

I am using NOS11C-A.EXE

Is there any parameter to adjust that?


THANKS!!!

===============================================
Guy Boulais, VE2GYB
e-mail: [e-mail]
e-mail: [e-mail]

------------------------------

Date: Wed, 19 Oct 1994 23:09:04 GMT
From: [e-mail] (Mike Morris)
Subject: RTTY ?

FOR SALE, TRADE, OR ????

One Model 28 ASR Teletype, complete.
  Includes spare Model 28 RO less cabinet
    i.e. a spare printer mechanism with base.

The 28 ASR has a regular friction feed platen.
  The 28 RO is equipped with a pin feed platen,
  vertical and horizontal tab kits (was used to print
  airline tickets).  If you really want it I have the
  Teleticketer (tm) control box - essentially a 300 baud
  autoanswer modem with answerback and a loop current generator.

This unit has been in storage in the back of my garage for the last
5-6 years when the current owner moved from a house into an
apartment and asked if he could store it in my garage.  I believe it
was working at that time.  He has since lost interest in it, and told
me to get rid of it.  Manuals _might_ be available - if any interest
is shown, I will put the prospective buyer in touch with the current
owner.
--
Mike Morris   WA6ILQ   | All opinions must be my own since nobody pays
PO Box 1130            | me enough to be their mouthpiece...
Arcadia, CA. 91077     |
ICBM: 34.12N, 118.02W  | Reply to: [e-mail]

------------------------------

Date: 19 Oct 94 19:44:54 GMT
From: [e-mail] (Byon Garrabrant)
Subject: Send .COM files over e-mail

Send .COM files over e-mail and packet

[e-mail] (Brian Kantor) writes:
>Or better yet, instead of using UUENCODE, which uses characters that
>aren't going to survive some e-mail gateways, use the MIME standard
>that does.  Why gosh-golly, if you use one of the standards, you might
>even find that you don't have to write code to use it, because your
>mailer might already understand it.
>
>But then, being compatable and following standards would take all the
>fun out of it, eh?  That's why we're AMATEURS, right?
>- Brian

I believe that unless the recipient of the file/message has a MIME
decoder, they will be completly unable to use a MIME file sent to them.
There may be many Internet e-mail reader which automatically de-MIME
thnigs for you, be I'd bet very few hams on packet have even HEARD of
the MIME standard.  CODET's purpose is to facilitate the sending a
binary file when the recipient has no more software than a terminal
program and a text editor.  It's a little different than MIME's
purpose.  I suppose I could have written the program to decode a MIMEed
.COM file, but I have seen UUENCODE used more than MIME, I don't know of
any packet TNC's that won't pass the characters I used, and what
difference does it make to the end user?

73, Byon

----------------------------------------------------------------------
Byon Garrabrant                KD6BCH             [e-mail]

------------------------------

Date: Thu, 13 Oct 1994 08:17:22 -0400
From: [e-mail] (Karl Beckman)
Subject: WANT: Computer Aided Dispatch system

In article <3792jm$[e-mail]>, [e-mail] wrote:

>
> I would like to know what info turns up here. Several people who work for me
>
> will be attending a meeting at the Dulles Marriott this week to discuss 911
>
> service for PCS and Celluar users.
>
>
>
>  In article <[e-mail]>, <[e-mail]> writes:
> > Newsgroups: rec.radio.amateur.digital.misc
> > Path:
>
> interramp.com!psinntp!rutgers!netnews.upenn.edu!msuinfo!caen!spool.mu.edu!sol.c
>
> tr.columbia.edu!news.msfc.nasa.gov!news.larc.nasa.gov!lerc.nasa.gov!purdue!yuma
>
> !csn!nowhere!aitsun20!sjames
> > From: [e-mail] (Scott James)
> > Subject: WANT: Computer Aided Dispatch system
> > Message-ID: <[e-mail]>
> > Sender: [e-mail] (Internet News Administration)
> > Nntp-Posting-Host: aitsun20
> > Organization: TeleCommunications, Inc.
> > X-Newsreader: TIN [version 1.2 PL2]
> > Date: Fri, 7 Oct 1994 21:16:59 GMT
> > Lines: 14
> >
> >
> > I'm looking for a Computer Aided Dispatch (CAD) system
> > that links radio modem technology with a GIS display.
> > These systems are used by Federal Express (I think)
> > and 911 agencies.
> >
> > If you know of any products or companies that can help
> > me find such a system, please email me with the info.
> >
> > thanks in advance!
> >
> > scott james
> > N0LHX
> >

To the unnamed pp000814 -
As a subscriber and nationwide roamer using cellular mobile service, I have
found that every cellular or PCS provider has a different method of
interfering when I dial 9-1-1 to report a serious problem on the highways.
There is no reason that direct emergency calls to 9-1-1 should be hindered
in this way. I found that the wireline cellular carriers in
Michigan/Indiana publicize their *-1-1 service, but it just goes into a
continuous ring cycle, and of course nobody answers their "O" lines either
when you try to report the problem.

I believe so strongly in universal 911 access that I am planning to author
a formal request for FCC rulemaking in the near future.  So, to get
directly to your inquiry, what is needed?
An FCC requirement that every radio-based voice communications service
provider shall directly route any call to 9-1-1 to the local PSAP
appropriate for the general area where the call was originated (The same
algorithms used to provide automatic transmitter site selection based on
signal strength can be used to provide the call routing data).   Further,
each carrier must provide caller ID information to each PSAP, which is
already provided for landline callers. Third, a direct callback input shall
be provided so that every PSAP nationwide has the ability to re-dial and
re-establish communications to the radio unit without dialing multiple
carriers, their various switch access codes, and finally the radio
subscriber's assigned number.  In short, radio-based comm carriers must
have service identical to that provided today by landline telephone
providers, and at no charge, so that radio-based subscriber units shall
have equal access to 9-1-1 services.

Scott - Motorola has provided quite a large number of computer-aided
dispatch systems, partnering with various software houses and mainframe
suppliers to build very complex interfaces to the "head-end" dispatch
center.  You should understand that the data protocols used over the air
for the roaming data terminals are not the same ones you use fearlessly for
direct hardwire connections.  I am aware of some the issues at FedEx, but I
think you need to talk to professional folks in the radio and computer
industries, not radio amateurs.

--
Karl Beckman, P.E.                  <     If our English language is so  >
Motorola LMPS.RNSG.Analog Data      <  precise, why do you drive on the  >
(Square waves & round corners)      <  parkway and park on the driveway? >
   Opinions expressed here do not belong to or represent Motorola Inc.
Amateur radio WA8NVW                        NavyMARS NNN0VBH @ NOGBN.NOASI

------------------------------

Date: 19 Oct 1994 15:24:28 -0700
From: [e-mail] (Todd Jonz)
Subject: Where is "ethrax25.zip"?

About a month or so ago there was a thread running in this group about the
upcoming availability of device drivers for DOS and/or Windows that would
support KISS on Winsock.  One helpful gentleman (whose name and call I have
unfortunately misplaced) suggested I have a look at:

    ftp://ftp.ucsd.edu:/hamradio/packet/tcpip/incoming/ethrax25.zip

I only just got around to following up on this pointer last evening, and was
disappointed to discover that this file has been corrupted.  Does anyone know
of another site from which this archive can be obtained?  Or if the author(s)
happen to see this note, perhaps you could repost a clean copy to UCSD?  Tnx,


KB6JXT, Todd

------------------------------

Date: Thu, 13 Oct 1994 09:00:03 -0400
From: [e-mail] (Karl Beckman)

References<[e-mail]> <[e-mail]>, <[e-mail]>
Subject: Re: 56k+ Packet System

In article <[e-mail]>, [e-mail] (Daniel T Senie)
wrote:

> In article <[e-mail]>,
> Gary Coffman <[e-mail]> wrote:
> >In article <[e-mail]> [e-mail] (Daniel T Senie) writes:
> >>In article <36u4fd$[e-mail]>,
> >>Victor Voronkov <[e-mail]> wrote:
> >>>Erich Muschinske ([e-mail]) wrote:
> >>>> Don't be too fast to dismiss this idea.  One of the things packet networking
> >>>> desperately needs is a cheap high speed data link.  This is necessary for
> >>>> operating a cellular packet concept.  It would only have to work with the
> >>>> radio on the other end, so adapting would not be out of the question.  If
> >>>> the price of a link could come down to about $600, I would be very interested.
> >>>IMHO any attempt to get speed more than 9600 on HandHeld or other 'voice'
> >>>Radio is problem. Even if we find new modulation. With half-duplex
> >>
> >>Can I ask a question here? How is it possible to get the necessary S/N ratio
> >>and other such to get a V.32bis modem to operate correctly over a Cell Phone?
> >>It seems to me that it IS possible for cell phones to provide a clean enough
> >>signal to do data over them, so why do hams have so much trouble getting
> >>the needed S/N ratio to run at 9600? I must really be dense and missing
> >>something. I understand that the example of V.32bis (14.4kbps) over cellphone
> >>is point-to-point. So are most amateur 56K links. Why can't we do a high
> >>speed link over inexpensive gear and limited bandwidth? It seems to work
> >>for cell...
> >
> >You *are* missing something Dan. It's not SNR that's the problem. While
> >it's true that most ham HTs are sorely lacking in adequate SNR over many
> >paths for *any* type of modulation, including voice, hence the term handi-
> >scratchie, that's *not* the main problem. Cellular phones are like the
> >rest of the telephone system in that the phone network handles the addressing
> >and routing *out of band*. This means that when the phone rings, the modem
> >*knows* the signal is for it, and can initiate a *training* sequence with
> >the modem on the other end to equalize and utilize the one transmission
> >path then in use. It is an *exclusive* circuit with no other modem signals
> >present.
>
> Most of the high speed packet usage I've seen has been for dedicated point-
> to-point links. At least that's the case up here in the northeast. When
> that IS the case, the issue of multiple signals goes away (or let's assume
> so for the sake of discussion).
>
> Assume two radios of known manufacture (and same brand and model just to
> ensure all is the same). Assume FULL DUPLEX on two frequencies, so that
> both ends are ALWAYS keyed and transmitting. This eliminates the call setup
> issues.
>
> Now, I still do not understand how a cell phone can get 14.4kBPS through
> a channel where we could not do the same on a dedicated, full duplex
> circuit.
>
> I understand fully the switching mechanisms, dedicated point-to-point nature
> of telephones, and the like. What I really want to hear more about is the
> actual data over a voice grade telephone circuit part of things.
>
> >
> >The only difference that a cellular modem faces versus wireline modems
> >is occasional signal dropouts due to handoffs, and the usual multipath
> >concerns. Therefore special modem parameters have to be used such as slow
> >disconnect so that the modem won't drop the connection during a brief handoff
> >outage, and robust error detection to handle the multipath induced symbol
> >errors.  We already have all that in packet.
> >
> >What we *don't* have on packet is out of band routing and addressing,
> >and what we *don't* have on packet is *exclusive* use of a frequency
> >for a pair of stations. A packet modem has to successfully decode the
>
> We do have many dedicated frequency links up here.
>
> >header of *every* packet on the channel to assure that the packet either
> >is or is not addressed to it. It *cannot* initiate a training sequence
> >every time it hears a packet it can't decode. *That's* why packet modems
> >can't use training, and training is the key to high speed data over a
> >voice grade circuit. Every telco modem over 2400 baud uses some form
> >of training at call setup. In packet, setup must be on a packet by
> >packet basis, and that won't work because not all packets on the
> >channel are addressed to the same modem.
>
> So if we were to construct equipment for dedicated links as I described
> above, and used training, then we'd be able to get 14.4K or 28.8k data
> rates over a 3kHz wide voice passband? (again assuming the dedicated
> pair of frequencies, and RF gear of known design).
>
> >
> >With the typical Kenmore, Yahoo, Icky, and Motrash radios used by
> >amateurs, no two of them will have the same bandpass characteristics.
> >Training is *essential* to compensate for that, and for off channel
> >stations. Amateur equipment doesn't have the frequency stability of
> >commercial equipment, so it isn't unusual to have one or more radios
> >a kilohertz or more off channel. Nor is it unusual to see wide differences
> >in deviation from one radio to the next, even among those of the same
> >make and model. Any modulation used has to be tolerant of all those
> >errors *without* compensation on a packet by packet basis. That's why
> >systems as slow as 9600 baud are difficult to setup with more than
> >two stations. 2400 baud is about as fast as an uncompensated system
> >can work with multiple players.
> >
> >The limitation is *not* with the modems, it's with the *radios*.
> >To successfully use high speed packet, we *must* have radios with
> >identical response characteristics, and that means dedicated data
> >radios, all optimized for the *same* response. Now it may be possible
> >to compensate *all* radios the same way in a system by use of DSP,
> >but it's not likely. There are two many variables outside the control
> >of the DSP, such as whether the radio is on channel center or not,
> >and the differing multipath from one radio path to the next. We
> >need identical radios, *and* a modulation that is tolerant of certain
> >types of errors. Such systems exist, I keep pointing to the GRAPES
> >56kb RF modem as an example, but insistance on using voice grade
> >amateur equipment for high speed packet is futile. Amateur packet
> >networks are *not* like the telco network, and telco techniques
> >won't work.
>
> I guess I'd always assumed that the GRAPES stuff was used to build backbone
> links of a network. From the issues you raise, it appears that this is
> a misconception, and that you have set up networks of multi-access
> stations over GRAPES modems at 56K. Is this correct?
>
> --
> ---------------------------------------------------------------
> Daniel Senie                 Internet:     [e-mail]
> Daniel Senie Consulting                    [e-mail]
> 508-779-0439                 Compuserve:   74176,1347


Gary, please pardon me if I put words in your mouth.  I've been tracking
the thread for a while and I agree with both your goals and implementation
plan.


Dan, I think you missed some of the most basic principles that Gary has
been trying to make to the amateur community for several years now;

1)  You MUST build high-speed networks out of units that perform
consistently, predictably, and in a nearly identical fashion.  If you
don't, you spend more time in establishing and maintaining the circuit than
in moving the data.

2)  GRAPES is not a just modem, not just a radio, not just a digital (ONLY)
modulation method.  It IS an integration of all three items into a package
with documented, useable (and rather impressive), and repeatable
performance parameters.

3)  Amateur radio packet networks are BY DEFINITION multipoint networks
that must operate reliably while having non-exclusive use of the radio
channels.  Data links made through telephone networks, conversely, are not
shared and are not multi-point.

--
Karl Beckman, P.E.                  <     If our English language is so  >
Motorola LMPS.RNSG.Analog Data      <  precise, why do you drive on the  >
(Square waves & round corners)      <  parkway and park on the driveway? >
   Opinions expressed here do not belong to or represent Motorola Inc.
Amateur radio WA8NVW                        NavyMARS NNN0VBH @ NOGBN.NOASI

------------------------------

End of Ham-Digital Digest V94 #346
******************************